The Evolved Packet System (EPS) provided by the 3rd Generation Partnership Project (3GPP) is composed of the Evolved Universal Terrestrial Radio Access Network (E-UTRAN), the Mobility Management Entity (MME), the Serving Gateway (S-GW), the Packet Data Network Gateway (P-GW, or PDN GW), the Home Subscriber Server (HSS) and the Authentication, Authorization and Accounting (AAA) server.
When an H(e)NB accesses the Evolved Packet Core (EPC), in order to guarantee the security, the security gateway (SeGW) is introduced in the evolved core network, and the H(e)NB establishes an IPSec tunnel with the security gateway at first before communicating with the equipment of the core network. The control plane communication data and the user plane data between the H(e)NB and the equipment of the core network are all encrypted by that IPSec tunnel. FIG. 1 is a system framework diagram of an H(e)NB accessing the core network. As shown in FIG. 1, this framework supports the traditional GERAN/UTRAN and the Long Term Evolution (LTE) access simultaneously; wherein, the Home NodeB (HNB) is a home base station supporting the GERAN/UTRAN, and the Home eNodeB (HeNB) is a home base station supporting the LTE. The home base station gateway (Home NodeB Gateway, HNB GW) is mandatory when the HNB is adopted to access. The HNB needs to register with the HNB GW when the HNB is power-on. The evolved home base station gateway (Home eNodeB Gateway, HeNB GW) is optional. When the HeNB GW is deployed, the HeNB registers with the HeNB GW; when the HeNB GW is not deployed, the HeNB is registered to the MME.
According to the 3GPP protocol, when the UE accesses from the H(e)NB (that is, HNB or HeNB), the MME or the Serving GPRS SUPPORT NODESGSN (SGSN) or the HNB GW performs the access control on the UE. When the UE attaches through the H(e)NB, if the UE and the network support the Closed Subscribe Group (CSG), the H(e)NB notifies the CSG identity (CSG ID) supported by itself to the SGSN or the MME. The SGSN or the MME judges whether to allow that user to access from that H(e)NB according to the user subscription data obtained from the HSS. When the UE attaches through the HNB, and if the UE or the network does not support the CSG, the HNB GW judges whether to allow that UE to access from that HNB according to the UE IMSI list allowed by the HNB and configured locally.
In the above-mentioned process that the UE accesses through the H(e)NB, all relevant messages are all protected by the security tunnel between the H(e)NB and the SeGW. The H(e)NB establishes the security tunnel with the SeGW and authenticated with each other when power-on, therefore, the H(e)NB is believable from the viewpoint of the SeGW. However, the relevant protocol is unable to guarantee that the identity sent to the MME/SGSN/HNB GW by the H(e)NB is the same with the identity during the mutual-authentication with the SeGW. In fact, in a lot of scenes, the H(e)NB uses the identity in the MME/SGSN/HNB GW, which is different from the one during the mutual-authentication with the SeGW. According to the current protocol, the SeGW is not responsible for the authentication of the identity used by the H(e)NB in the MME/SGSN/HNB GW.
Therefore, according to the relevant protocol, the H(e)NB can illegally use other's identity subsequently when communicating with the MME/SGSN/H(e)NB GW. For example, the HeNB1 uses the true identity (this identity is based on the certificate or based on the hosting party module (HPM)) to establish the IPSec tunnel and mutual-authenticate with the SeGW first; when the UE accesses from the HeNB1, the HeNB1 sends the HeNB ID of the HeNB2 and the CSG ID supported by the HeNB2 to the MME. According to the CSG ID of the HeNB2, the access of the UE is allowable; however, the access of the UE will not be allowable if it is based on the CSG ID supported by the HeNB1. In the above-mentioned example, the HeNB1 illegally uses other's identity, thus enabling the user, who is originally not allowed to access, to be able to access the network, thus destroying the security of the network.
To that problem, someone proposes a method that a new interface is added between the SeGW and the MME/H(e)NB GW and the SeGW sends the association relationship between the H(e)NB ID and the inner IP address of the H(e)NB to the MME/H(e)NB GW, to authenticate the identity of the H(e)NB in the core network (that is, the identity used in the MME/H(e)NB GW). However, this method has a lot of defects, specifically including that: the association relationship between the H(e)NB ID and the inner IP address of the H(e)NB can only be triggered by the IPSec message to send to the MME//H(e)NB GW when the H(e)NB is power-on, and the SeGW needs to select an appropriate MME//H(e)NB GW to send that association relationship, and needs to guarantee that the H(e)NB selects the same MME or H(e)NB GW when the H(e)NB is registered, therefore, it needs to guarantee that the H(e)NB selects the same MME or H(e)NB GW during the specific implementation, which will undoubtedly increase the difficulty of realization. And, if the H(e)NB does not select to send the MME or H(e)NB GW of its own identity when it is power-on originally, this method will be failed. According to the relevant protocol, the H(e)NB selects the MME or H(e)NB GW according to the configuration information of the H(e)MS, but there is no interface between the SeGW and the H(e)MS, so it is very difficult to guarantee that the MME and the H(e)NB GW selected by the SeGW are the same as the H(e)NB and the MME selected by the H(e)NB GW. And, in this scheme, it is assumed that the MME and the H(e)NB GW is the authentication server of the H(e)NB, however, according to the relevant protocol, the authentication based on the HPM module is optional, therefore, the authentication of the H(e)NB may not need to be applied to the AAA server, which makes that scheme unable to be suitable for all scenes.